Coding JavaScript for Mobile Browsers (part 7)

2.10. Waking up

As we discussed in the previous section, on most devices timers (and all JavaScript execution) are paused when the web page is sent to the background. I have an iPod Touch, and in Safari I always have my email open in one of the eight possible tabs (or windows). When I want to browse to another website, I change to another tab but leave that one open. That means my email can be frozen for several hours or even days, until I go back to that tab. As developers, this raises an important issue: when our web pages are put into the background, how can we detect when they should “wake up” again?

Neil Thomas, a software engineer from Google working in the Gmail for Mobile team, has published a very simple and clever solution using a high-frequency timer and a global variable for calculating the time elapsed between calls to that timer. Because the time will not fire when the application is in the background, if we detect that the delta time from the last execution is greater than a certain threshold value we can assume that the timer firing again indicates that the application has just woken up from hibernation.

Note:

Remember to use a large value for the threshold after deciding that the page has gone to sleep. Otherwise, depending on the tasks being done, the engine behind the browser, and the device hardware, it may take longer for the JavaScript code that’s executing to complete than the time defined for the timer.

This is Thomas’s public code (with a little variation from me). An explanation can be found at http://www.mobilexweb.com/go/timers:

// The time, in ms, that must be "missed" before we
// assume the app has been put to sleep.
var THRESHOLD = 10000;

var lastTick_;
var detectWakeFromSleep_ = function() {
  var now = new Date().getTime();
  var delta = now - this.lastTick_;
  if (delta > THRESHOLD) {
    // The app probably just woke up after being asleep.
    notifyWakeFromSleep(delta/1000);
  }
  lastTick_ = now;
};

In the notifyWakeFromSleep method, you can decide what to do based on the received parameter telling you how many seconds have passed since the last active state. You may want to do different things if the delta time is 10 seconds or 1 day (86,400 seconds). For example, after a big delta you might want to show a warning or a loading animation while new results are fetched using Ajax.

Warning:

There is one situation where we won’t have the opportunity to wake up. If the device is running out of memory and our page is in the background, it is possible that the browser will delete the page state to release memory, and when the user comes back to it our page will be loaded by URL as a new session.

Remember that after waking from sleep, the document and the script are in the same state (including their HTML content and JavaScript variables) as they were before going to sleep. iOS before 4.0 doesn’t support multitasking, but Safari stores the state of every window even when it is closed.

2.11. Changing the title

In desktop web applications, it is common to change the title dynamically to alert the users of a change in the page, when updates are made in an Ajax application, or simply as an animation (please, don’t do this!).

In mobile browsers, this isn’t such a good idea, for the following reasons:

• Many browsers don’t even display the title.

• If the user is working with many tabs at the same time, dynamically changing the title won’t be useful because your web page will be frozen when it is in the background.

• Animations in the title can be annoying in a mobile browser.

2.12. Regular expressions

Regular expressions are a great way to validate input and perform other tasks. They are included in the JavaScript 1.5 standard, but some low- and mid-end devices may not include regular expression algorithms. Still, Table 12 shows that this is a very compatible feature across browsers.

2.13. Cookie management

Cookies are a great solution for the problem of statelessness in HTTP. As you’ll see in Table 8-13, they work on practically all modern devices. This is good. The bad thing is that the lifetime of a cookie can be shorter in the mobile ecosystem than in the desktop world, especially in low- and mid-end devices, because of the lack of memory storage.

Warning:

It is recommended to maintain cookies’ values at below 2 KB for the best compatibility in mobile devices.

Cookies are normally stored and read by the server, but JavaScript also allows us to read and write them as a client-side storage mechanism. As Table 13 shows, all the major platforms support cookie management from script code.